home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group02b.txt
/
000120_icon-group-sender_Tue Nov 19 12:48:19 2002.msg
< prev
next >
Wrap
Internet Message Format
|
2003-01-02
|
2KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAJJmDg21892
for icon-group-addresses; Tue, 19 Nov 2002 12:48:13 -0700 (MST)
Message-Id: <200211191948.gAJJmDg21892@baskerville.CS.Arizona.EDU>
From: jleger@afslogistics.com (Jonathan Leger)
X-Newsgroups: comp.lang.icon
Subject: I know why Icon isn't popular.
Date: 19 Nov 2002 10:31:38 -0800
X-Complaints-To: groups-abuse@google.com
To: icon-group@cs.arizona.edu
Errors-To: icon-group-errors@cs.arizona.edu
Status: RO
To ward off the flames, let me first say that Icon is the most elegant
programming language that I've ever used. I love it. It takes the
"mundane" issues like storage and typing out of the hands of the
developer and lets him focus on what's really important: application
functionality.
But Icon lacks the tools and technologies needed by real-world
applications programmers, at least in the Windows world. It does not
have (or at least I am not aware of it having):
1) A strong IDE.
2) A strong visual GUI developer.
3) Built-in real-world database support (though Unicon took care of
this with ODBC).
To be accepted into the world of Windows application programmers, Icon
needs:
4) Support for technologies like COM+.
5) The ability to compile Icon libraries to DLLs for use in other
languages.
In fact, if Icon could just do #5 I would gladly write the middle-tier
for my database applications in Unicon for the ODBC and just use a
good front end like Visual Basic for making pretty forms.
My $0.02.
Jonathan Leger